前情提要：

軟體工程師在開發時，不僅僅需要將需求的功能代碼給寫出來，同時也必須測試所寫出的功能是否正確，因此今天要來和大家分享，在撰寫測試時所需要注重的點還有概念！

最小功能為單位：

以下為收銀台的服務，在裡面可以看到有兩個是獨立運行的功能，分別是「計算賺入」和「計算支出」，因此在單元測試時，會測試其各別功能是否有達成預期效果，而非測試整個收銀台的服務和流程。

Dependency Injection（依賴注入）：

在撰寫功能時，有一些會去針對資料進行處理，例如資料庫和 API 的，這時，撰寫此功能，並不會將此資料的獲取也連同寫在一起，而是去呼叫專門在呼叫資料的函式。

• 原因：在進行資料庫連線，或是 API 請求時，有機率會有連線上的問題，而導致無法正常運作，若這時又將此寫近功能當中，這樣除錯就會變得稍微複雜，因為還需要判斷是程式碼邏輯的問題，還是請求時連線上的錯誤，因此把資料的請求和程式邏輯分開來，隔離不可控的資料，會使開發上效率更高。
• 注入方式：
  1. Constructor Injection（建構子注入）
  2. Field/Property Injection（欄位/屬性注入）
  3. Method Injection（方法注入）

Test Double（測試替身）：

若確實依照上面的形式撰寫功能，則在測試時，會將獲取資料的函式用此概念來代替，以下講解概念。

• 角色：
  1. SUT（System Under Test）：為你待測試的程式。
  2. DOC（Depended-on Component）：此指的是當你在 SUT 執行時所使用的資料，例如資料庫、API等等，在測試時會需要避免使用到這些。
• 種類：在測試時因為要避免 DOC 的使用，因此會根據情況使用不同種類來進行替代，以下為各種類和其使用時機
  1. Dummy：測試完全用不上，只是為了滿足編譯而傳入 SUT 當中。
  2. Stub：只會回傳固定值，用來驗證狀態。
  3. Spy：只會紀錄 SUT 和 DOC 之間的行爲互動，用來驗證行為。
  4. Fake：有接近原始物件的行為，但以較為簡單的方式進行。
  5. Mock：為 Mocking framework 產生，可以快速做到 Dummy, Stub, spy 的功能。